My 2 cents about the API changes:

• The only class that the user needs to see in order to implement a new type is PackageTypeProvider. Since users that implement this interface are service providers, I would put it in a spi package. The package must have an @Export annotation, so it is marked as exported by BND.
• The remaining classes can be in an non-exported package. I would suggest calling it internal, so even non-JPMS users understand that the package is not part of the public API. The ServiceLoader JavaDoc even recommends this:

  It is strongly recommended that the module does not export the package containing the service provider.

• Nit: I find putting each implementation of PackageTypeProvider a little bit verbose. These classes need to be public, but they can be nested classes of a single top level class.
• JPMS and OSGi don't read the META-INF/services files. To declare a class as service, the @ServiceProvider class from biz.aQute.bnd.annotation can be used (see documentation):

  @ServiceProvider(value = PackageTypeProvider.class, resolution = Resolution.MANDATORY)

  This will generate all the necessary JPMS, OSGi and even the META-INF/services file. The current BND goal jar does this, when it creates the JAR, which is too late for unit tests, so we need either keep a manually generated META-INF/services file or switch to the bnd-process goal.
• The class that calls ServiceLoader needs to be annotated with:

  @ServiceConsumer(value = PackageTypeProvider.class, resolution = Resolution.MANDATORY, cardinality = Cardinality.MULTIPLE)

@ppkarwasz I made most of the changes you suggested, but I need to know how to update the pom.xml and bnd.bnd files:

[WARNING] bnd.bnd [0:0]: jpms.jarname calculated module names from file name: [org.osgi.resource-1.0.0, org.osgi.service.serviceloader-1.0.0]
[ERROR] bnd.bnd [0:0]: Requirement osgi.extender resolution not correct
[ERROR] bnd.bnd [0:0]: Requirement osgi.serviceloader cardinality not correct
[ERROR] bnd.bnd [0:0]: Requirement osgi.serviceloader resolution not correct

• biz.aQute.bnd.annotation can be used (see documentation):

@ppkarwasz There seems to be duplicated classes between this and org.osgi.annotation.bundle. I am not sure which to prefer, since I think both dependencies end up being necessary.

• This will generate all the necessary JPMS, OSGi and even the META-INF/services file. The current BND goal jar does this, when it creates the JAR, which is too late for unit tests, so we need either keep a manually generated META-INF/services file or switch to the bnd-process goal.

@ppkarwasz I think it's better to auto-generate this file if we can.

@ppkarwasz I am stuck on the OSGi errors. I don't have experience creating a bnd file manually as opposed to plugins that generate the MANIFEST.MF bundle headers.

I am stuck on the OSGi errors. I don't have experience creating a bnd file manually as opposed to plugins that generate the MANIFEST.MF bundle headers.

I'll check it out.

What bothers me a little with the current proposal is that type-specific normalization and validation only occurs when normalize and canonicalize is called. Looking at the "Tests" section of the spec and in particular:

• parsing the test purl should return the components parsed from the test canonical purl

I deduce that the components should only and always be stored in normalized form (and be valid). So the PackageTypeProvider interface should probably a validate-and-normalize method for each component, so that it can be used in the constructors.

I like this approach - each type can implement the type-specific normalization.